home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001464_daemon _Mon Jun 28 05:30:02 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA11849; Mon, 28 Jun 93 05:30:04 MET DST
  3. Return-Path: <phillips@cs.ubc.ca>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA11845; Mon, 28 Jun 93 05:30:02 MET DST
  6. Received: from relay.cdnnet.ca by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA18311; Mon, 28 Jun 1993 05:53:18 +0200
  8. Received: by relay.CDNnet.CA (4.1/1.14)
  9.     id AA13505; Sun, 27 Jun 93 20:53:14 PDT
  10. Date: 27 Jun 93 20:53 -0700
  11. From: George Phillips <phillips@cs.ubc.ca>
  12. To: <www-talk@nxoc01.cern.ch>
  13. Message-Id: <5886*phillips@cs.ubc.ca>
  14. Subject: browser execution
  15.  
  16. I've thought about this business of getting a WWW browser to execute
  17. a program and I've convinced that a new URL scheme is necessary
  18. for some uses.  In particular, you need it if you want to repeatedly
  19. run a program which outputs HTML (or MIME) and generally acts like
  20. a server.
  21.  
  22. An executable MIME content type is good for "one-shot" executions
  23. (like a "mail developers" link which runs a mailer), but it can't
  24. cover the more dynamic semi-server case.  Why?  Because you need
  25. a MIME document to back up each URL your server outputs that
  26. refers back to the server.  This is fine with an HTTP server, but
  27. for a browser-executed server it means having a file for every
  28. link which defeats the purpose.
  29.  
  30. A hack to the file: scheme is mostly OK except that it limits executable
  31. things to file: (no big deal with the MIME executable content type),
  32. is not particularly abstract (it points to a specific file) and leaves
  33. the relative URL semantics hanging.  Look at the HTML output of
  34. file:/bin/rn.html%/comp/sources/misc.  If it outputs the anchor
  35. <A HREF=/comp/binaries/mac>mac</A>, does that mean
  36. file:/comp/binaries/mac or file:/bin/rn.html%/comp/sources/mac?
  37. The writer of "rn.html" would certainly prefer the latter over
  38. having to constantly spit out full references, but the former is
  39. what should really happen.  Sure, we could pass in the full URL
  40. to rn.html so it knows the path, but that seems pretty messy.
  41.  
  42. So how about this:  an "exec:" scheme that looks like:
  43.  
  44.     exec://encoded-URL/opaque/stuff/like/other/URLs
  45.  
  46. Semantics: decode the "encoded-URL", grab it and execute it
  47. with the rest of the URL.  I used the  "//" notation so
  48. that executables can ouput "/" rooted URLs without having
  49. to know who they are, that is, rn.html can say "<A HREF=/comp/risks>".
  50. We can do the "encoded-URL" any way we like, but suppose that
  51. : -> ; and / -> \.  A full exec: URL might look like:
  52.  
  53.     exec://file;\bin\rn.html/comp/sources/misc
  54.  
  55. However, with the MIME executable content type, I'd expect that
  56. most exec: URLs would point to files, so file: would be the default.
  57. Additionally, the browser might have some notion of a PATH for
  58. exec: files (possibly as a first-level security mechanism), so the
  59. whole thing could be shortened to:
  60.  
  61.     exec://rn.html/comp/sources/misc
  62.  
  63. I fully realize that these URLs probably won't work between different
  64. sites.  I don't expect WWW servers to be sending you these any time
  65. soon (unless they're trying to delete all your files :-), but
  66. it's possible if some general agreement on the symbolic names
  67. happens.  For instance, it may become agreed that
  68. <A HREF=exec://mailer/mosaic-guys@ncsa>bug report</A> will
  69. fire up some kind of mail program.
  70.  
  71. While the file: with %/ hack is workable, I think this is better.
  72. What do you think?